The present specification relates to apparatus, methods and computer programs for controlling retention of data messages in a publish/subscribe messaging environment. A publish/subscribe messaging environment is typically an asynchronous messaging paradigm where publishers do not send their messages directly to specific receivers. Rather, the published messages are characterized into classes. The subscribers express interest in one or more classes and receive messages within these classes. Many conventional publisher-subscriber models used fixed, pre-named classes to decouple the publishers and subscribers (for example “stock\IBM”). In these publisher-subscriber models, the publishers and subscribers are unaware of each other's existence. These classes may be created using a variety of methods, including filtering the published messages by topic or by content. In topic-based filtering, the publisher is responsible for assigning the message to a particular topic. In content-based filtering, the subscriber specifies content attributes that define content they wish to receive. Publish/subscribe systems may support topic-based filtering, content-based filtering, both, or a hybrid of the topic and content based filtering.
In many situations, the publish/subscribe model is facilitated by an intermediary broker who serves as a repository for published messages and performs filtering and distribution functions. By only loosely coupling the publishers to the subscribers through a broker, the publishers and subscribers can operate independently from each other. Further, because the broker handles the implementation of the publish/subscribe system, the publishers and subscribers can utilize the system without a knowledge of the system details. Additionally, the publication/subscription model can provide better scalability than the traditional client-server topologies.
Normally, a publication is deleted after a copy has been delivered to all subscribers. However, in some situations publications are ‘retained’ by the broker, maintaining a copy of a message even after it has delivered it to all subscribers. A retained publication allows a subscriber to asynchronously request the retained publication instead of relying on it being delivered by the pub/sub broker. These types of messages normally contain state information, and are also referred to as state publications.
A retained message, such as one containing state information, can become out-of-date or otherwise incorrect. For example, a message concerning the time at which an event will take place may no longer be useful, and indeed may even be confusing, to any subscriber once the event has already taken place. Thus, a mechanism for removing such retained publications is required.
One known mechanism for this comprises specifying an expiry time in the message, which tells the broker that the publication is to expire at a particular time or in a certain number of minutes. However, this is inflexible as the expiry time must be preset when the message is sent. Another known mechanism comprises the manual deletion of the message once it becomes known that this is out of date. However, this mechanism can be onerous, time-consuming and slow. The present specification addresses these problems.